Glad to report it's fixed. After several existential crises I found the problem. Ends up while I was doing 498758967456798430674551 different things, I swapped some ports around, and got some bad routes. For whatever reason, PFSense preferred the bad routes to the good one. So I just went to "Diagnostics --> States --> Reset States" and reset all (literally the only option). Anyway, after giving everything a minute or two....it all just worked. I have no idea why those routes didn't clear out, but it's CERTAINLY a tool I'll remember in the future!!!

+1 there you go. ;-) -Rico

my rsyslog.conf under ubuntu rsyslogd 8.32.0 # provides UDP syslog reception module(load="imudp" timeRequery="8" batchSize="128" threads="2") # needs to be done just once input(type="imudp" port="514") if $programname == 'dhcpd' then /var/log/pfsense-dhcpd.log & stop cat /var/log/pfsense-dhcpd.log May 20 19:29:37 172.16.0.254 dhcpd: Internet Systems Consortium DHCP Server 4.4.1 May 20 19:29:37 172.16.0.254 dhcpd: Copyright 2004-2018 Internet Systems Consortium. May 20 19:29:37 172.16.0.254 dhcpd: All rights reserved. May 20 19:29:37 172.16.0.254 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ May 20 19:29:37 172.16.0.254 dhcpd: Config file: /etc/dhcpdv6.conf May 20 19:29:37 172.16.0.254 dhcpd: Database file: /var/db/dhcpd6.leases May 20 19:29:37 172.16.0.254 dhcpd: PID file: /var/run/dhcpdv6.pid you also need to check centos firewall/selinux

The OpenVPN gateway IP may not respond to ping. Try setting some other external IP to monitor across it.

@Gertjan said in Disable nginx access log (to remote syslog server): True, these "access logs" are not really needed and do pollute de remote log. @arrmo said in Disable nginx access log (to remote syslog server): /var/etc/syslog.d/pfSense.conf Noop. This is the one that controls syslogd : /etc/syslog.conf Yes, agree with you! I was thinking filtering at syslog, but I like your idea better It's build here 985 -> 1080 in /etc/inc/system.inc I tried to rebuild somewhat the last statement : Mine is : *.* @192.168.1.4 so it excludes logs from 'nginx' as a program, or "Local5" as the facility, but no access. OK, you lost me there, sorry. With *.* ... everything gets sent across, no? I may be missing your point. It's also possible to inform nginx to shut up. See line 1447 : access_log syslog:server=unix:/var/run/log,facility=local5 combined; in the same system.inc file. What somewhat seem to work without any pfSense file edits : Yes, agreed! I like this approach. I changed that line to , access_log off; And voila, after a webConfigurator restart (to regenerate the needed files) ... no "noise" from the access log. I think this is the best way to go, agreed? Another solution : On the remote site, filter out Local5.Info messages Right, but that still means all those messages going across => lots of bandwidth and horsepower chewed up (for no good reason ... agreed?) Thanks for the thoughts and pointers - much appreciated!

After you make any change to LDAP SSL settings, run 16 and 11 from the console menu (ssh or physical console). Then test things again. PHP gets weird sometimes when populating the environment variables needed for LDAP to work. Unfortunately the PHP settings to configure LDAP directly don't work. On 2.5.0 you could have both CAs added to the trust store for the OS which would also likely solve it.

Use the dual-home backup server if that's what you need. Make sure it cannot route between them though. If routing between those subnets is restricting the throughput then look into where that is. pfSense maxing out the CPU? You should be using different interfaces for the subnets, VLANs at least but preferably two NICs so you are not seeing throughput killed by the ACK traffic. Steve

@JKnott said in Issue with network and Gmail and other Google pages: Well, I'm allergic to Apple gear LMAO!

I thought of it as fine tuning: Path to file: /boot/loader.conf.local.......................... and these as well: System -> Advanced -> Miscellaneous -> Power Savings Check "Enable PowerD" and set to "Maximum" or Hiadaptive" for all power states.......................... Anyway, I'm glad you solved the problem. PS:Unfortunately, I can't open the link, so I don't know how good a description you found.

LPADS has been working for me for some time, including a test. A few minutes after trying to log out and log in to pfsense, I can’t log in anymore and the SSL connection does not work, I see the error "Unknown CA (48)" in network traffic. What reliable actions need to be done?

Oh so pfsense can do its "own" traffic through the snooping upstream proxy... This would have zero to do with clients behind pfsense - those clients would need to trust this CA as well.. Because the upstream proxy is doing mitm.. What gov is this?

@jimp said in Renewal of Internal CA: You could spin up a 2.5.0 VM, import your CA, renew it there, export, and then copy the contents back to your current setup. If it's that old, though, you'll probably also want to let the renewal process upgrade it to a stronger key/hash/etc. Thanks for the great feedback.

@Druplex said in Unable to load dynamic Library: @Gertjan am on 2.4.4-p3, i had upgraded to 2.4.5 but gave me the same same error so i just reverted back and the error is still on. Ok. Packages were updated / upgraded to support 2.4.5 and PHP dependencies. You can't upgrade packages using and 'old' version of pfSense like 2.4.4-p3 if a 2.4.5 exists, as the package could actually need (example) PHP 7.2.b) while pfSense 2.4.4-p3 is using 7.2.a. There will be a PHP library version mismatch. That what you are seeing. Normally, when you upgrade pfSense, you don't stop there. The list with installed packages will also get updated, and show you if any packages should be upgraded. At that moment, these upgrade might not be optional, as they could use old (PHP) libraries, and pfSense just replaced them with more recent ones. This explains the error you saw. Just finish upgrading, and all will be fine. Downgrading pfSense will not help here. Golden rule : Do not install/upgrade (use ?) packages any more as soon as a new version of pfSense comes out and you decide to stay on the old version. That is : closely observe what sub packages, like PHP, get installed with it them. Some will work on neraly any version of pfSense, some use a lot of shared resources with the OS or other pfSense core files, and need to get upgraded - at least re installed. See Netgate release notes. Netgate's upgrade video and the huge quantity of forum posts about the subject. Keep in mind : most packages are created by people like you and me. Package maintainers should only have to support their package using the latest pfSense version. No one want to make a package installable on all kind of recent and ancient pfSense version (like Microsoft doesn't support his older versions neither, it's just to much of o job).

I finally got to make the change and have been monitoring the last week with great success. We haven't had one error in the last 10 days which leads me to believe that changing the time has fixed the issue we were experiencing. Before we had it set to 00:00 CEST now it's set to 12.00 CEST.

The firewalling and NAT are done in pf, not ipfw. If you enable the captive portal, it uses ipfw for the CP blocking functions. Perhaps you were thinking of ipfwSense.

@JKnott said in Increase swap size: @Raffi_ I also wonder why you'd need more swap on a router. However, in the Linux world, it's possible to create a swap file, which serves the same function as a swap partition. Perhaps the same is possible with FreeBSD. Thanks, that's a good point. I will not spend any time looking into ways to do it even if it is possible. It was just something I was curious about more than something I needed. If for example it was a single command I could have run and it was fool proof, I would have gone for that. But being that in the case of pfsense it would be a partition adjustment. There is no way I'm doing that. Especially, for something that really isn't necessary as you point out.

@stephenw10 First of all, thanks for your answer. I tried with Outbound NAT in automatic mode and in manual mode with the rules: WAN1 10.128.10.0/24 * * * WAN1 address * this is not a rule to the WAN 2 where the 192.168.104.0 network exists. Should i make a NAT rule to WAN2 ? Something like: WAN2 192.168.104.0/24 * * * WAN2 address * ? I also tried to enable the Bypass firewall rules for traffic on the same interface setting. Unfortunately i still not able to reach the 192.168.104.0 network from the 10.128.10.0 or visa versa. I thought adding a static route on each firewall and add the correct firewall rule (to allow traffic from the other network on the concerning interface) should do the trick? but how i understand from you i miss something (NAT?) ? Note that i can ping the Zyxel USG200 interface and devices of the 192.168.104.0 network from the Pfsense diagnostics ping tool but not from my computer.

@stephenw10 , Thank You